如何比較效益、成本，以及不做的代價？

前幾天從「重新處理」按鈕，談到批次操作與排隊期間的狀態變化，需要照顧的地方越來越多。

今天先往回看：營運人員原本的困難，是訂單呼叫庫存服務逾時後，無法確認結果，只能等工程師協助。如果系統能查明結果，並安全地接續處理，還需要由人按下按鈕才開始嗎？

先確認自動恢復的條件

假設庫存服務能用固定的操作識別查詢扣減結果，重複收到同一筆操作時，也能避免再次扣減，系統就可能在逾時後自動恢復。

但要注意：訂單號碼唯一，不代表庫存只會扣一次。 訂單資料表不允許重複編號，無法阻止庫存服務收到第二次請求時，再扣一次數量。

我們要確認：第一次呼叫與重試是否沿用同一筆操作識別？多個品項、扣減與釋放能否區分？防重紀錄與庫存異動是否保持一致？同一識別也不能任意更換商品或數量，重試則須落在防重紀錄有效的期間內。

這些條件經過驗證後，背景工作就能先查詢結果：已扣減，就同步訂單狀態；仍在處理，就稍後再查；符合補送條件時，才沿用原識別重試。

「查不到」也不能直接當成「沒扣」。原請求可能還在執行，查詢資料也可能尚未同步，要依服務契約判斷。結果未明就保留待確認；訂單已取消或不再符合條件，也不能照原樣繼續扣減。

人工操作還剩下什麼？

如果多數逾時都能在可接受的時間內恢復，營運人員可能只需要看處理進度，以及哪些訂單仍需關注。原本的批次勾選、全選與確認送出，就不一定都要做。

超過約定時間仍查不明的訂單，則需要呈現已有證據，交由人員核對，再決定下一步。多放一顆「重試」按鈕，並不會讓未知的結果變得已知。

人工入口也必須遵守相同的處理條件與防重規則，避免背景工作與人員同時操作，造成重複扣減。

把效益和代價一起算

不過，現有庫存服務也可能沒有上述能力。要補上查詢與防重機制，還得協調另一個團隊排程。自動化值得考慮，但不一定是現在最適合的投入。

我會整理技術條件與預估工作，和團隊比較：

假設一個月只有兩筆異常，每筆核對五分鐘，也不影響出貨，維持現況可能足夠。若一天六十筆，同樣每筆五分鐘，就是每天五小時的人工作業，還沒算等待與交接。

實際討論要依據事件紀錄與處理時間，也要看延誤的影響。有些異常一次就可能耽誤出貨，不能只看平均工時。

自動恢復也有持續成本。服務故障時，重試需要限制速率與次數，超過處理期限要能告警並交接。按鈕少了，這些工作仍然要有人維護。

團隊可以先列清楚待確認訂單，再加入安全的自動恢復。若暫緩，也要約定異常量、等待時間或作業影響達到什麼門檻時，重新評估。

AI很快做出來之後，還要看什麼？

回這個例子，假設我們提供完整規格，讓AI沿用專案既有模式完成批次按鈕、API與測試。看著畫面能操作、測試全綠，很容易覺得：「都做好了，就上吧。」但這些成果還沒回答：營運人員以後是不是仍要每天進來勾選？

我會在實作前，請AI追查現有的結果查詢、防重機制與背景工作，附上程式位置，比較「人工觸發」與「自動恢復」各要補哪些能力。若再提供實際異常紀錄，就能估算哪些訂單可以自動處理，哪些仍需人工判斷，讓方案比較有具體依據。

驗證也可以繼續交給AI協助，但要看它測到了什麼。例如測試把庫存服務替身設定成「第一次逾時，第二次成功」，只能驗證重試路徑；還需要模擬「第一次已扣庫存，只是回應遺失」，核對重試後是否只扣一次。若沒有下游實作或整合環境，就要把這項保證列為尚未驗證。

AI 能協助我們分析方案、實作與驗證，讓功能更快完成。但決定要不要做，仍要把後續維護與營運的代價一起算進去，並用上線後的結果確認問題是否改善。開發者需要理解的，也包括什麼時候調整流程就已足夠，不必再多做一個功能。

去年AI正火熱的時候，老闆也想了不少LLM可能派得上用場的功能
討論時很有畫面：AI先理解Dashboard的情況，自動決定下一步。聽起來終於要輪到我們做點有AI味的東西了

結果把情境一個個攤開，確認輸入、判斷條件是什麼、每種情況要做什麼之後，規則越來越明確，留給LLM發揮的空間也越來越小。

最後發現，這次要解決的問題，用幾個if else就夠了。
功能有完成，問題也有改善，整個過程中，最有AI含量的部分，是我請AI把那幾個if else寫出來